Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

How did I achieve my CBAP?

Trividh Patel, CBAP — Sat, 09 Mar 2019 12:19:00 GMT

At first, I wanted to tell people how they should go about getting their IIBA certification. But then I thought the best way to do this is by actually telling “how did I achieve my own CBAP?” So, friends here is my story.

I started working as Business Analyst in 2002. I have used multiple elicitation techniques (such as interviewing, workshops, focus groups, etc.) and different requirements analysis techniques such as process modelling, use case modelling, user stories, prototyping, business rules analysis, non-functional requirements analysis, business case development etc. I have had good experience in business analysis projects working for clients worldwide.

By 2011, I already had about nine years of experience in business analysis when I have decided to go for my CBAP certification.

First thing I did was to check if I was eligible to apply for IIBA CBAP certification. So, I studied IIBA CBAP handbook and understood that IIBA evaluates business analysis experience in terms of 6 knowledge areas and I was supposed to have total of 7,500 hours of business analysis work experience and minimum 900 hours in at least 4 knowledge areas to apply for CBAP certification.

So, I studied IIBA BABOK guide version 2.0 and understood various business analysis tasks under each of the 6 knowledge area. This was the latest IIBA BABOK guide at that time. I started analysing my project experience from the IIBA perspective. I have listed down all the projects I have worked in my career and identified different business analysis tasks and activities I have performed and figured out number of hours I must have spent in each of those tasks and activities. I aggregated number of hours as per knowledge area and also calculated total hours of my business analysis experience.

To my surprise, I had well over 7,500 hours of business analysis experience and over 900 hours in all the 6 knowledge areas.

Next thing was to get 2 professional references and out of that one was supposed to be current contact. So, I approached my career manager and explained him benefits CBAP will bring to the organisation as well as to me. He gladly agreed to provide recommendation. Next, I approached single point of contact from one of the client organisation and he too agreed to provide me recommendations for CBAP certification. I have also contacted various colleagues from past projects and companies and got their buy-in in case IIBA would want to audit my project experience.

Next thing was to ensure I fulfil professional development in terms of contact hours. I understood from CBAP handbook that training can be in any area directly related to business analysis. As I already have had enough business analysis work experience, I thought of attending full time lean six sigma certification training. Please note that the training provider was NOT an Endorsed Education Provider or an EEP and still it was accepted by IIBA. Many people don’t know that IIBA does not mandate training provider to be an EEP but mandates training to be relevant to the business analysis and must be instructor led classroom or virtual live (for CCBA and CBAP application). However, for ECBA application training can be online without instructor.

After attending training, I have submitted online application on the IIBA website. I have provided information such as my education and work history details such as Project Name, Start and End dates, project Description, Total BA hours, Project contact details and various BA activities performed. I have also provided professional training details and two professional references.

After submitting application, I have paid application fee online. Within a week I received confirmation email from IIBA that my application was approved and I am supposed to pass the certification exam in 1 year from the date of approval email.

So I started preparing on my own for CBAP certification. I have studied IIBA BABOK guide at least 4 times. I have correlated concepts in the IIBA BABOK guide to my actual project experience. I have also figured out ways to remember concepts such as involvement of stakeholders and use of techniques in various business analysis tasks. It took me over 6 months to prepare.

Once I was confident I have identified nearest venue available for taking the exam and paid the exam fee.

I have registered and scheduled my CBAP exam for 15-March, 2012.

The exam venue was almost at one and half hour drive from my home and this time was subject to traffic conditions. So, I tried searching for a hotel near exam venue but there was no hotel nearby. So, I have approached a friend whose house was fortunately nearby the exam venue and he gladly agreed to let me stay overnight.

So, I stayed at my friend’s place and next day I reached venue on time. I showed my exam conformation emails and proofs of identification to the exam supervisor. I used provided username and password to logon the exam application.

I started attempting CBAP exam but soon I have started experiencing noise from other desks. I requested people and also to exam supervisor but it was of no use. Just then I remembered that I have ear plugs. Use of ear plug really helped to significantly reduce the noise and let me attempt exam without much disturbance.

I again started attempting questions. I have flagged certain questions for which I was not very confident. After attempting all the questions, I revisited flagged questions and took calculated risks and tried to figure out the best possible answer. After doing this, I still had about 20 minutes so I quickly browsed through all the questions and answers. I found couple of mistakes made while selecting my choice of answers. I made corrections and submitted my answers for evaluation.

Within just 30 seconds, I got message on my screen that I have successfully passed my CBAP exam!

I got email from IIBA confirming the same. I was also informed that my name will be included in list of CBAP recipient on the iiba website and also that I shall receive my certification kit in another 2 months time. I was also told that from now on I was licensed to use CBAP in my name and in my communication.

Well, that was my story and I am sure you too would have yours one day. All the Best!

About Author - Trividh Patel, CBAP

Trividh Patel has over 17 years of experience in Business Analysis and Consulting in IT services industry.

He has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organisations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt (CSSBB).

Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

Business Requirement: Clarified

Praveen Udupa — Fri, 06 May 2016 09:38:00 GMT

"Business Requirement" is a maligned phrase. Different people have different interpretations for what it means. The worst interpretation that I have come across is, “hey, if the requirement comes from a business stakeholder, then it is a business requirement”. Requirement from business is NOT business requirement. For God's sake, every requirement comes from a stakeholder, otherwise it is not a requirement.

In this blog, I wish to clarify what exactly is a business requirement. I base this entirely on the best practice definitions documented in the BABOK v2 (and v3…truth rarely changes!)

Let’s take a short case:

Assume there is an insurance company that is dealing with a sticky business problem: they have a significant proportion of the policies lapsing by the first anniversary. In other words, the customers who buy an insurance policy today do not renew it the following year and, instead, let the policy lapse. Upon performing root cause analysis, the insurance company determines that the customers do not care to renew their policy because they don’t like to travel all the way to the branch office to pay the premium in order to renew their policy. In fact, they find commuting to the branch office so troublesome that they find it acceptable to let their policy lapse.

Now, what does this insurance company need to deal with the policy lapsing problem?

The insurance company requires an Ability To Collect Premium Remotely. This is a business requirement.

According to the BABOK, a business requirement is simply a statement of goal, objective or outcome of why a change is initiated. (Please see my P.S. at the end of this article)

Let’s take a closer look at the above business requirement:

Business Requirement exists in the Problem Domain. It captures the need of the business in order to eliminate a problem (actually the symptom). If the insurance company develops the ability to collect premium remotely, then, according to the root cause analysis, more customers will be willing to renew their policies, and consequently the lapse rate will decline.
Business Requirement MUST NOT capture how it will be met, i.e. the statement of business requirement must not include the solution. This is important. Very important. Well, why is this so? There are a couple of reasons:
1. First: Business requirements are developed during Enterprise Analysis (BABOK v2) or Strategy Analysis (v3). To be more specific, they are developed after assessing current state of the organization. At this point in time, no one even know what the solution is because it is not yet identified. Hence the question of including the solution in the statement of business requirement does not even arise.
2. Second: there always are multiple potential solutions that can be employed to meet a business requirement. If the statement of business requirement includes a solution, one would tie the organization to the said solution without considering any of the other solutions. In the above insurance company example, there are several solutions possible:
  - First obvious solution: enable internet and mobile payment
  - Enable direct debit from the customer’s bank account
  - Partner with one or more banks and enable the banks to collect the premium
  - Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
  - Establish several satellite premium collection centres

As you can see, any one or more of the above solutions will provide the remote premium collection ability to the insurance company. Thus, it is not prudent to include the solution in the statement of business requirement.

Most people whose role/designation is Business Analyst operate in the IT space. They define the requirements for an IT solution. More often than not, these BAs do not get to define the business requirements because they mostly never participate in Strategy Analysis projects. However, every BA participating in defining the User and Solution requirements MUST begin by understanding the Business Requirements.

More on this in my subsequent blogs...but for now, I will look forward to your comments!

P.S:

BABOK is probably confusing for a first time reader (even if this first time reader is a seasoned BA). The BABOK makes a confusing statement - it says business requirements are high level statements of goals. This seems incorrect because a goal and requirement are clearly two different things. Here is how I reconcile various terms:

First comes Business Strategy
Business Goals are defined from Business Strategy
Business Objectives are SMARTly decomposed from Business Goals
Business Requirements are high level statements of goals (not Business Goals) in order to eliminate a Problem that is preventing the org from meeting its Objectives, without including any indication of the Solution in its statement
Stakeholder Requirements (or User Requirements) are needs of Stakeholders from the selected Solution, in the context of a Business Requirement
Solution Requirements define the behavior of and constraints imposed on the Solution in order to deliver the Stakeholder Requirements

Things to know before you start your BA career

Bharat Mamtani — Mon, 25 Apr 2016 02:18:00 GMT

Now when I am already a successful BA since many years, I would like to share few moments with everyone.

During my first months as a business analyst, life was filled with a sort of inner turmoil. Even though I had books on how to write requirements documents, had received individual mentoring on putting together use cases, and had a trusted set of templates to follow, there was something uncertain about how the business analysis process would actually unfold.

I found myself making a lot of mistaken assumptions about what to expect, having those assumptions prove to be unfounded, and then needing to find ways to adjust and course correct. Looking back, there is nothing unexpected about my experiences, except that they were unexpected to me at the time.

Knowing that many of you are just getting started, today I am sharing 4 of the things I wish someone had told me when I was just starting out in my business analysis career.

Need to set expectations early and often, and then again and again and again…

As a business analyst, it’s not uncommon to receive too many assignments, tasks that are outside your bailiwick, or unreasonable deadlines. I was surprised to find myself constantly explaining what I was doing, why it was taking so long, and what could be expected of me over the coming weeks, even though I didn’t always know what the next week would look like!

I also found that deadlines would seem reasonable but became overly optimistic when I didn’t hear back from stakeholders in a timely manner, couldn’t get time on the calendar with a critical stakeholder for weeks at a time, or encountered unexpected issues.

I learned to continually clarify my role, communicate about what would be done when, and seek feedback to be sure I was meeting expectations.

Getting information could be a little painful

Early on in my career, I naively expected unlimited access to stakeholders and their unhindered involvement in and passion about my projects.

The reality was much different. My stakeholders had multiple projects, conflicting priorities, and too much to do. Even when my project was important to them, it could still be difficult to get the information I needed in a timely manner.

Over my career, I learned to be a bit of a squeaky wheel – a very polite, diplomatic, and conscientious one – but squeaky nonetheless. My projects started to move more smoothly and I met my deadlines with less angst.

Although being the requirements author, you aren’t the requirements owner.

I love to write and I love to write requirements. But I could get so caught up in writing and documenting and modeling that I would take on more ownership than was prudent. This would lead to a lack of buy-in from critical stakeholders, which could translate to unexpected changes late in the project.

The reality is that we absolutely need stakeholders to take ownership of the content going into the requirements document, even as we author that document on their behalf. And yes, they are likely to resist reading, reviewing, and providing feedback on requirements.

I learned that providing early, incomplete drafts that were clearly imperfect would help stakeholders see that they could add a lot of information and clarity into the requirements. I also learned to be very specific about the status of any given deliverable when sending it out, and equally specific about what I was asking of my stakeholders of this document at this time.

Dealing with issues professionally would take a new kind of finesse

I’ve always been a proactive person and a bit of a whistle-blower. When a new issue surfaced, I would signal the alarm, rally the troops, and facilitate a problem solving meeting.

However, discovering requirements is a gradual process of gaining clarity and minimizing ambiguity. At a certain point in time, every requirement was once an issue. Business analysis surfaces so many issues that you can’t possibly resolve all of them immediately.

With experience, I learned to blow the whistle more softly, keeping everyone informed about what was surfacing, but not unnecessarily alarmed. To keep the requirements process moving forward, I also learned to take ownership of the issues that surfaced inside of the requirements, and make more decisions about how to resolve issues and which options to choose or recommend.

Now that you know what to expect

Now that you know what to expect, perhaps you won’t be as caught off-guard as I was during your first days as a business analyst!

Happy Analysis !!!

BABOK v2 - End-to-end data flow diagram analysis can highlight issues

Alan — Thu, 10 Jul 2014 01:20:00 GMT

As part of preparation to sit the IIBA CBAP exam, I wanted a one page summary of the overall BABOK flow. The first step of creating a summary matrix showing a derived master list of documents (e.g. Inputs + Outputs) versus the process that creates or uses it was interesting, but not entirely helpful.

By using the matrix to create an indicative data flow type diagram, that helped to better understand the overall end-to-end process documented in the BABOK.
Note: Clear stakeholder information was not available so a Business Process type Model was not possible.

The data flow type visualization technique is very useful:
1. It is an additional visual means of communicating complex information for people who struggle with understanding just text.
2. It quickly shows the flow of information between the various processes
3. The data flow diagramming conventions help to highlight issues. E.g. No clear sources or uses of specific deliverables, redundant and reverse flows etc.

This is also timely given the review of the Draft BABOK v3 material that has been requested and that closes on July 11th.

BABOK 2.0 Launch

Craig Brown — Mon, 30 Mar 2009 12:12:00 GMT

Kevin has shared the beginnings of the IIBA's BABOK 2.0 chapter on Enterprise Architecture with us all on his website. We'll be digesting it in the next few days.

In the meantime there is an online launch of the new BABOK and you are invited. It's tomorrow so check out the details now.

John Zachman at UK IIBA Meeting in February

Alex P — Thu, 05 Mar 2009 13:51:00 GMT

John Zachman provided an extremely entertaining introduction to the Zachman framework followed by an update on forthcoming IIBA activities from Martyn Wilson, chairman of the IIBA.

John Zachman

Many of you will have heard of John Zachman as his framework has been around for thirty five years or so. It is used for that much discussed, little understood art/science of enterprise architecture (could be just speaking for myself here ;-)).

John provided us with a funny, engaging and compelling presentation which was peppered with amusing anecdotes and asides. As well as being entertaining, it was a very good introduction to enterprise architecture and, more importantly, the business case for enterprise architecture.

His starting slide (and we’re talking old school projector acetates – John betrayed his academic grounding here!) explained Enterprise Physics.

To sum up, he explained how enterprises are no different to anything else in the universe, they are subject to the laws of physics and, if ignored, you will feel pain. He described enterprise architecture as a long term, not a short term endeavour and our current problem (or pain) is chronic, not acute.

He went on to explain how enterprise architecture is perceived as an information technology issue for a couple of reasons:

i) The problem is raised by the IT department

ii) The skills to solve it exist in IT

In passing, John explained how the end objective of enterprise architecture is the manufacture of an enterprise, NOT an IT system. Also, he quoted Fred Brookes in the Mythical Man Month who explained how programming is manufacturing, NOT engineering.

John showed us a slide of the colliseum and explained how many people mistakenly perceive this as architecture. The architecture was completed some time before the first stone was dragged on to the site. The building is simply one instance of that architecture. In theory, many more could have been created.

Why do we need architecture?

John explained that we don’t need architecture when:

- The object is unlikely to change

- We can perceive it in its entirety at one time

- It is simple

He explained why enterprise architecture is often perceived as an IT issue:

- The problem is raised by the IT department

- The skills to resolve it exist in the IT department

Alternatives to enterprise architecture

John explained three alternatives if we don’t have an enterprise architecture when embarking on a significant change within an organisation using the analogy of extending our room to seat 1500 from its current capacity of 100:

i) Change it anyway and take a risk. Make sure you don’t knock down any supporting walls!

ii) Reverse engineer the architecture. This will be a challenge – it might not be possible

iii) Knock it down and start again. Sounds drastic and expensive

John discussed how the Information Age is emerging from our current Industrial Age and how it is characterised by extreme complexity and extreme rates of change. In other words, our current challenges are only going to get worse.

Zachman framework

John explained the basis of the framework as a set of abstractions combine with a set of perspectives which form a matrix.

: Zachman framework

This can be downloaded as a PDF from John's website.

There was a great deal more to John's presentation but you will find many of these messages reflected on his website.

As a final comment, the message John delivered was that it is undoubtedly a very hard and challenging job to commit to creating and maintaining an enterprise architecture. There are no short cuts, however, it is necessary and critical for an organisation to be successful.

IIBA Update

Martyn Wilson gave an update on events and items of interest to the IIBA membership as follows:

Conference is planned for 28th to 30th September
with prices varying and big discounts available for multiple applicants or company applications. Prices before discount are £1,145 with discounts of 30% available (nothing on the website at the time of writing)

Conference objectives are -

increase awareness
deliver professional development opportunities
examine trends in the role
demonstrate how to be a high performing BA
promote and develop the community

The type of subjects to be covered are:

Introduction to business analysis
Future of business analysis
Secrets of top performing BA's
BA success stories
Creating a BA community

Finally, there are three 'directors at large' positions available. Nominations will be accepted from 16th March and will close at 30th March with an announcement at the end of April.

The next event will be presented by Steve Danby (head of business analysis at Prudential) on creating a successful business analysis community (25th March).

Do you have what's in the BABOK?

Craig Brown — Sat, 19 Jan 2008 18:34:00 GMT

How do you measure up against the IIBA's BOK. Take a quick self assessment and then work out a personal development plan to help you get ready for certification.

| View | Upload your own